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SERVICE LOGIC PORTABILITY BA SED ON INTERFACE DEFINITION 
OF EXECUTION ENVIRONMENT IN AN INTELL IGENT NRTWn RE 

Background Of The Invention 
5 This invention relates generally to service logic 

provisioning for an intelligent network (IN) and, in 
particular, to a methodology for producing service logic in 
a service creation environment based upon the IN execution 
environment . 

10 The intelligent network architecture has been 

evolving through the efforts of international standards 
committers including the ITU-T (formerly CCITT) , American 
National Standards Institute (ANSI) , and the European 
Telecommunications Standardization Institute (ETSI) ; and 

15 regional specifications organizations including Bellcore. 
This evolution is driven by the demand for rapid 
development and deployment of services in the 
telecommunications network. The ITU-T specification 
"Revised ITU-T Recommendation Q.1214 - Distributed 

20 Functional Plane for Intelligent Network CS-1" and the 
draft ITU-T specification "ITU-T Recommendation Q.1224 - 
Distributed Functional Plane for Intelligent Network 
Capability Set 2" provides a general model for network 
element execution environments such as the service control 

25 function (SCF) and specialized resource function (SRF) . 

ITU-T specifications Q.1205 "Intelligent Network Physical 
Plane Architecture" and Q.1215 "Physical Plane for 
Intelligent Network CS-l n relate these functions to 
physical platforms, such as, a service control point (SCP) , 

30 intelligent peripheral (IP), service switching point (SSP) 
and services node (SN) . 

Similarly, the Bellcore specification "AIN SCP 
Generic Requirements Application Support Processing" GR- 
1280 CORE, Issue 1, August 1993 defines a service 
3 5 provisioning architecture for the advanced intelligent 

architecture (AIN) SCP, While these specifications provide 
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the basis for service provisioning and execution in 
Intelligent Network execution environments (EEs), they do 
not address the need for a flexible means to enable 
portability of service logic created by different vendors 1 
5 service creation environments (SCEs) while also allowing 
for flexibility in the service provisioning process. 
Services require tailoring to meet specific subscriber 
needs, in addition to defining the behaviour of the 
service . 

10 Intelligent network telecommunication services are 

typically developed using a high-level programming 
environment generally referred to as the SCE. 
Telecommunication services are provisioned, that is 
telecommunication subscribers are assigned to the service, 

15 through a service management system (SMS) . Service 

information is downloaded to the EE, which could be either 
a SCP, an IP, a SN, or a SSP or any combination of these 
intelligent network elements. 

Under current practice, each EE is implemented in 

20 a vendor specific manner. Typically, the capabilities of 
the vendors SCE match the capabilities of their EEs. To 
provide service ubiquity for all service subscribers and 
users, service providers and operators must redefine 
(manually) services for each different EE in the network, 

25 leading to inconsistent service behaviors, translation 

errors, and delay of service introduction. As an interim 
solution, some operators target specific services to 
specific vendors products. However, this leads to 
deployment and interworking issues, including service 

30 coverage concerns. 

A conventional approach for achieving service 
logic portability utilizes cross compilation techniques and 
intermediate languages, whereby an output service logic 
program from the SCE is translated into a form suitable for 

35 the target EE. For example, U.S. patent number 5,488,569, 
issued January 30, 1996 to Slutsman et al, teaches an 
intermediate language called Application Oriented 
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Programming Language (AOPL) and an associated 3 -pass 
compilation process to mediate between the various SCEs and 
execution environments. The Slutsman approach, however, 
infers a process for service creation. Specifically, the 
5 AOPL depends on a strict representation for service logic, 
namely program code to be output directly from the SCE, 
Other methodologies for service capture exist which 1) 
manipulate service logic during provisioning phase, or 2) 
use an interpretive execution environment. Therefore, AOPL 
10 requires a more flexible means of capturing different SCE 
outputs . 

Furthermore, the telecommunications industry is 
currently standardizing use of Application Programming 
Interfaces (APIs), which abstract EE functionality and 

15 provides a simple means of invoking that functionality. 
Examples include: 

International Standard ISO/IEC 9595 : 1991 
"Information technology - Open Systems Interconnection - 
Common management information service definition" describes 

20 services which are used to convey management information to 
underlying operations. These services are in essence APIs 
used to manage telecommunication systems. 

Internet Engineering Task Force, Network Working 
Group, Request For Comment 1508 "Generic Security Service 

25 Application Program Interface" defines APIs which provide 
security services APIs on the internet. The definitions 
support a variety of underlying mechanisms and 
technologies . 

Bellcore specifications TA-TSY-000924 "Service 

30 Logic Interpreter 1+ Framework" and SR-TSY-000778 -Service 
Logic Interpreter Preliminary Description" provide a 
framework for a service logic execution environment using 
APIs. 

However, these specifications also do not address 
35 a flexible service provisioning process based on the 
current intelligent network architecture. 
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A flexible and efficient means to enable 
portability of service logic created by different vendors' 
SCEs, while also allowing for flexibility in the service 
provisioning process to the EE is desirable, 
5 Summary O f The Invention 

It is an object of the present invention to 
provide a new and improved methodology for service logic 
provisioning . 

The invention, therefore, according to a first 

10 aspect provides a method of defining behaviour of a service 
for a subscriber in an intelligent telecommunications 
network, comprising the steps of: providing interface 
definitions according to which respective functions in an 
execution environment (EE) of the network are invokable; 

15 accessing, at a service creation environment (SCE) , the 
interface definitions to construct a service logic 
representation of the service, wherein the SCE selects 
individual interface definitions which are utilized to 
specify corresponding function invocations within the 

20 service logic representation; and providing the service 

logic representation together with data of the subscriber 
to the EE. 

According to another broad aspect, the present 
invention provides a system for defining behaviour of a 

25 service for a subscriber in an intelligent 

telecommunications network, comprising: a repository of 
application programming interface (API) primitives which 
define how to invoke respective functions in an execution 
environment (EE) of the network; a service creation 

30 environment (SCE) for constructing a service logic 

representation of the service, wherein the SCE access the 
repository and selects individual API primitives which are 
utilized to specify corresponding function invocations 
within the service logic representation; and means for 

35 providing the service logic representation together with 
data of the subscriber to the EE. 
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International patent application number 
PCT/CA95/00297, by K. Borg et al, published on December 14, 
1995 under number W095/34175, teaches a technique for 
achieving more flexible service provisioning. The Borg 
5 technique relates to defining services by data and not 

executable software code. This provides a simpler and more 
predictable provisioning process, as data is easier than 
software to deploy in an EE. 

In a particular embodiment of this invention, the 
10 Borg technique is employed together with a library of 

interface definitions whereby both portable and flexible 
service provisioning may be achieved. Application 
programming interfaces (APIs) are being standardized in the 
telecommunications industry and may be utilized as the 
15 interface definitions. These APIs provide multi -vendor 

interworking through their standardization, while allowing 
vendors flexibility in implementation options. 

Thus, the present invention characterizes means to 
facilitate portability of service logic to various EEs 
20 created by different vendor SCEs while allowing for 

flexibility in service provisioning platform and process 
implementation. Advantages of this invention include that 
it allows for use of industry standardized Application 
Programming Interfaces (APIs) of the EEs as the basis from 
25 which to facilitate portability. Furthermore, it makes use 
of this API knowledge directly within the SCE. The SCE 
output format provides appropriate primitives for API 
invocation. At the same time, it allows for flexibility in 
the means through which SCE outputs are provisioned on the 
30 EEs through the provisioning platform and process. 

Brief Descripti on Of The Drawings 
The invention will be better understood from the 
following description of the service provisioning 
methodology together with reference to the accompanying 
35 drawings, in which: 

Figure 1 illustrates the ITU-T standardized 
Intelligent Network Functional Architecture as given in 
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draft ITU-T specification Q.1224 "Distributed Functional 
Plane for Intelligent Network Capability Set 2 n ; 

Figure 2 illustrates the process flow for 
provisioning of portable service logic based upon execution 
5 environment APIs; 

Figure 3 illustrates different service logic 
provisioning and deployment approaches; 

Figure 4 illustrates a service logic 
representation based upon standardized APIs; and 
io Figure 5 illustrates in a block diagram a service 

logic execution environment in accordance with an 
embodiment of the present invention. 

Petflilefl Rescript App 
Referring to Figure 1, illustrated is the ITU-T 

15 standardized functional architecture for an intelligent 
network (IN) , in which a service creation environment 
function (SCEF) 10 provides the necessary tools for network 
operators or their agents to create behavioural 
representation for call and service processing. Output 

20 from the SCEF 10 is used by a service management function 
(SMF) 11 to provision the various execution environments 
which the service logic referenced in service execution. 
The SMF 11 updates the SCEF output to complete the logic 
for execution, for example, by associating appropriate 

25 subscriber data (eg. routing numbers) and execution 

environment data (eg. OMs) with the SCEF output. The IN 
execution environments include, but are not necessarily 
limited to, a service control function (SCF) 12, a 
specialized resource function (SRF) 13, and a service 

30 switching function and call control function (SSF/CCF) 14. 
As described in ITU-T recommendations Q.1205 and Q.1215, 
the functions of SCEF 10, SMF 11, SCF 12, SRF 13 and 
SSF/CCF 14 map to particular intelligent network physical 
elements, respectively, a service creation environment 

35 (SCE) , service management system (SMS) , service control 
point (SCP), intelligent peripheral (IP) and service 
switching point (SSP) . 
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Other functional elements of the IN architecture 
include a service management access function (SMAF) 15, a 
service data function 16, and a call control access 
function (CCAF) 17. Furthermore, element interconnections 
5 depicted as solid lines 18 represent service control, 

broken lines 19 represent management control, and beaded 
lines 20 are voice connections. The bars 21 indicate 
inter-network communications. 

Referring to Figure 2, shown is a service creatioi 
10 environment (SCE) 22 which provides the capability to 

create IN based services and which typically conprises a 
graphical user interface (GUI), decision graph editors, 
spreadsheets and computer aided software engineering (CASE) 
tools that facilitate creation of logic representations of 
15 such services. The SCE 22 is a widely recognized platform 
for vendor differentiation within the telecommunications 
industry, in that SCE output or service logic 
representation 23 may provide different capabilities and 
formats each being proprietary to a particular vendor. At 
20 the same time, however, there is a recognized need to 

enable portability of the service logic representation 23 
from the SCE 22 to a target execution environment 24 . As 
there are a wide variety of SCE implementations in 
existence, it is very difficult to specify requirements for 
25 either the format of the service logic representation 23 
or a process through which this service logic 
representation 23 is instantiated for the execution 
environment (EE) 24. 

Figure 3 illustrates several methods of deploying 
30 service logic and data. In Method A, using the SCE 22 

service logic 38a is created with the subscriber data 38b, 
defining specific behaviour, embedded within the logic 3 8a. 
The resulting SCE output is ready to be deployed into the 
execution environment 24 (physically the SCE output may be 
3 5 transfered to the execution environment via the SMS) . In 
Method B, the service logic 39 is defined for all instances 
of the service. Subscriber specific data 40 is captured at 
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the SMS 25. The service logic 39 references the subscriber 
data 40. In Method C, general service logic representation 
23 is created using the SCE 22. The service logic 41a is 
completed at the SMS 25 by defining subscriber specific 
5 options and data 41b. The service logic 41a and data 41b 
are then deployed to the execution environment 24. Each of 
these methods represent valid approaches to service logic 
definition and provisioning. Each method defines a service 
in terms of service logic and subscriber data. A method 

10 for defining service behaviour is required which 
accommodates these different approaches. 

Referring again to Figure 2, to achieve service 
logic portability while supporting a flexible service 
provisioning process, in accordance with the present 

15 invention, a repository 26 of execution environment 

interface definitions is utilized by the SCE 22 in service 
logic creation process 27 to construct a service logic 
representation 23. The interface definitions provide 
formal specifications by which respective functions 28 

20 supported within the execution environment 24 may be 
invoked. Examples of functions include geographical 
routing, time of day decision, and play message. Each 
interface definition includes a function identifier for 
invocation of its corresponding function 28 and identifies 

25 all input and output parameters needed by that function 28. 
These predefined function interfaces may be implemented as 
a software library that is imported or accessible to the 
SCE 22. The functions 28 may be implemented in the EE 24 
as executable (i.e., compiled ) software code or as 

30 interpretable rule based logic representations from which 
compiled code is effectively invoked. 

Advantageously, the repository 26 of interface 
definitions may comprise industry accepted Application 
Programming Interfaces (APIs) primitives. By standardizing 

35 the APIs, through defining its format, input parameters, 
output parameters, etc., which are encapsulated by the 
primitives 29, the IN service providers can specify and 



WO 97/36430 



PCT/CA97/00154 



create services suitable for multiple target execution 
environments 24. The API primitives reflect the interfaces 
of the EE functions 28 without specifying the detailed 
implementation of that functionality. The SCE 22 accesses 
5 the repository 2 6 of EE APIs and selects the individual API 
primitives 29 which are utilized to specify function 
invocations within the service logic representation 23 . in 
addition, the service logic representation 23 is 
constructed by the service logic creation process 27 using 

10 rules to control logic flow and building block invocations 
which also correspond to functions 28 in the EE 24. API 
primitives differ from building block processes in that the 
latter is a vendor or platform specific implementation of 
execution environment functionality. 

1 5 In this process, an executable service logic 

program (i.e., code) is not generated by the SCE 22 but 
rather an interpretable form of rules that represents the 
service logic. The service logic representation 23 
comprises data formatted according to a specific syntax 

20 whereby the rules are characterized, with individual rules 
being arranged to reflect the logic flow to be effected in 
the EE 24. 

The service logic representation 23 is 
subsequently provided as the SCE output to the SMS 2 5 which 

25 in turn provisions an EE instantiated SCE output 30 to the 
EE 24. Provisioning effected at the SMS 25, in accordance 
with the present invention, enhances portability of the 
service logic representation 23 format to different vendors 
EEs 24 using a flexible method of assigning subscribers to 

3 0 a service. The service logic representation 23 output from 
the SCE 22 reflects a general service logic flow 
incorporating all features that are supported for the 
service at the EE 24. On the SMS 25, the platform specific 
service logic provisioning function 32 processes the SCE 

35 output as a function of subscriber data 31 which includes 
subscriber specific options for the service, thereby 
generating the EE instantiated SCE output 30 which in turn 
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is downloaded to the EE 24. The EE instantiated SCE output 
30 constitutes a subscriber customized version of the 
general service logic representation 23 (i.e., a service 
logic representation which pertains to a specific 
5 subscriber) and, hence, is referred to as a subscriber 
service logic representation 33. 

In the EE 24, this subscriber service logic 
representation 33 is accessed by a service logic 
interpreter 34 which functions to interpret the rules 

10 governing logic flow, depicted in Figure 2 by flow graph 35 
in the representation 33. Accordingly, the interpreter 34 
invokes the functions 28 corresponding to API primitives 37 
and building block invocations 36 traversed during 
interpretation of the subscriber service logic 

15 representation 33 . 

Referring now to Figure 4, exemplified is an API 
primitive 42 which forms part of the subscriber service 
logic representation 33 and which represents invocation of 
a procedure identified as "a" . The API primitive 42 will 

20 have associated with it a precise syntax for invocation 

which is the list of appropriate input, output and modified 
parameters. In the example illustrated, API — a 42 
references a specific field 43 of a call data 44 record as 
input data for the first formal parameter parml 45, derives 

25 output data as second parameter parm2 47 and stores the 
output data in field 46 of the call data 44 record, 
references subscriber data 48 as input for the third 
parameter parm3 49 and certain platform data 50 for its 
fourth parameter parm4 51- The actual location or value 

30 for an API (or building block) parameter is defined during 
the creation of the service logic representation 33 . 

To further clarify this concept an exanple of a 
time dependent routing function will be used as API_a 42 . 
The first parameter parml 45 extracted from the call data 

35 record 44 may be the calling number. The second parameter 
parm2 47 which is output as a result of the function would 
be the routing number. The third input parameter parm3 49 
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could reference a time based routing table defined by the 
specific subscriber data 48, and which would provide the 
mapping of time of day slots to routing destinations. The 
fourth input parameter parm4 51 is extracted from the 
5 platform data 50 which provides a system clock value for 
instance . 

Figure 5 presents the major software and data 
components of an execution environment. The execution 
environment embodies several functions used to process a 
10 service request and to invoke a service for a particular 
subscriber. On receipt of an incoming message 52, a block 
of memory for storing call and service logic variables 53 
is allocated or retrieved 54 depending upon whether the 
incoming message is associated with a previously existing 
15 transaction. The memory block 53 is used to store all 
variables required during the execution of a service. A 
message decode 55 function extracts information from the 
message 52 which is used to determine the subscriber 
specific service to invoke and hence the parameter 
20 locations for use by the API primitives and / or building 
blocks . 

A retrieve subscriber profile 56 function uses one 
or more information elements resulting from the message 
decode function 55 to retrieve a subscriber service logic 

25 representation 57 from a subscriber profile database 58, 
which corresponds to the subscriber specific service 
offering. The record for the subscriber service logic 
representation 57 is extracted from the database 58 and 
provided to a service logic interpreter 59. The service 

30 logic interpreter 59 then navigates through the subscriber 
service logic representation 57. Functions effected by the 
interpreter include: 

determine which building block 60 or API primitive 
61 to invoke next; 
35 pass execution control to building block 60 or 

function represented by the API primitive 61; 
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• monitor for and handle error conditions; and 

• retrieve parameters values from various locations 
within the system and pass these values to building blocks 
60 and API primitives 61 as required. 

5 A message encode 62 process performs an encode 

function that takes variables from memory block 53 to 
generate an encoded outgoing message 63. This function is 
invoked after the completion of the service logic 
interpreter 59 • 

10 This invention provides a level of portability 

from various vendor SCEs through consistent use of industry 
standard APIs while accounting for flexibility in the 
service provisioning process employed. 

Those skilled in the art will recognize that 

15 various modifications and changes could be made to the 
invention without departing from the spirit and scope 
thereof. It should therefore be understood that the claims 
are not to be considered as being limited to the precise 
embodiments set forth above, in the absence of specific 

20 limitations directed to each embodiment. 
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WE CLAIM: 



1. A method of defining behaviour of a service for a 

5 subscriber in an intelligent telecommunications network, 
comprising the steps of: 

providing interface definitions (29) according to 
which respective functions (28) in an execution environment 
(EE) (24) of the network are invokable; 
io accessing, at a service creation environment (SCE) 

(22), the interface definitions to construct a service 
logic representation (23) of the service, wherein the SCE 
selects individual interface definitions which are utilized 
to specify corresponding function invocations within the 
15 service logic representation; and 

providing the service logic representation 
together with data (31) of the subscriber to the EE. 

20 2. A method as claimed in claim 1, wherein each 

interface definition includes a function identifier for 
invocation of its corresponding EE function and identifies 
any input and output parameters of that function. 

25 

3 - A method as claimed in claim 2 , wherein the 

interface definitions are contained in a software library 
which is accessible to the SCE. 

30 

4- A method as claimed in claim 2, wherein the 

service logic representation includes rules to control 
logic flow and building block invocations which correspond 
to other functions in the EE. 
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5* A method as claimed in claim 4, wherein the 

service logic representation is formed as data formatted 
according to a specific syntax whereby the rules are 
characterized . 

5 

6. A method as claimed in claim 5, comprising 
interpreting, in the EE, the rules of the service logic 
representation thereby effecting the service. 

10 

7. A method as claimed in claim 5, wherein the step 
of providing the service logic representation together with 
the subscriber data to the EE includes: 

15 providing the service logic representation to a 

service management system (SMS) ; 

instantiating, at the SMS, the service logic 
representation specifically for the EE; and 

providing the instantiated representation to the 

20 EE. 

8. A method as claimed in claim 7, wherein the 
service logic representation is a general service logic 

25 flow incorporating all features that are supported for the 
service in the EE; and the step of instantiating the 
service logic representation includes processing the 
general service logic flow as a function of the subscriber 
data which includes subscriber specific options for the 

30 service and EE platform specific data, thereby generating a 
subscriber service logic representation as the instantiated 
representation which is downloaded to the EE. 

35 9 . A method as claimed in claim 8, comprising, in the 

EE, accessing the subscriber service logic representation 
by a service logic interpreter which interprets the rules 
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governing logic flow and accordingly invokes the EE 
functions corresponding to the function invocations and the 
other functions corresponding to the building block 
invocations that are traversed during interpretation of the 
5 subscriber service logic representation. 

10. A system for defining behaviour of a service for a 
subscriber in an intelligent telecommunications network, 

10 comprising: 

a repository (26) of application programming 
interface (API) primitives (29) which define how to invoke 
respective functions (28) in an execution environment (EE) 
(24) of the network; 

15 a service creation environment (SCE) (22) for 

constructing a service logic representation (23) of the 
service, wherein the SCE accesses the repository and 
selects individual API primitives which are utilized to 
specify corresponding function invocations within the 

20 service logic representation; and 

means for providing the service logic 
representation together with data of the subscriber to the 
EE. 

25 

11. A system as claimed in claim 10, wherein API 
primitive includes a function identifier for invocation of 
its corresponding EE function and identifies any input and 
output parameters of that function. 

30 

12. A system as claimed in claim 11, wherein the API 
primitives are contained in a software library which is 
accessible to the SCE. 



35 
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13. A system as claimed in claim 10 , wherein the 
service logic representation includes rules to control 
logic flow and building block invocations which correspond 
to other functions in the EE. 

5 

14. A system as claimed in claim 13, wherein the 
service logic representation is formed as data formatted 
according to a specific syntax whereby the rules are 

10 characterized. 

15. A system as claimed in claim 14, comprising means 
for interpreting, in the EE, the rules of the service logic 

15 representation thereby effecting the service. 

16. A system as claimed in claim 14, wherein the means 
for providing the service logic representation together 

20 with the subscriber data to the EE includes a service 
management system (SMS) to which the SCE provides the 
service logic representation, and which instantiates the 
service logic representation specifically for the EE and 
provides the instantiated representation to the EE. 

25 

17. A system as claimed in claim 16, wherein the 
service logic representation is a general service logic 
flow incorporating all features that are supported for the 

3 0 service in the EE; and the SMS instantiates the service 
logic representation by processing the general service 
logic flow as a function of the subscriber data which 
includes subscriber specific options for the service and EE 
platform specific data, thereby generating a subscriber 

35 service logic representation as the instantiated 
representation which is downloaded to the EE. 
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18 • A system as claimed in claim 17, wherein the EE 

includes the subscriber service logic representation being 
5 accessed by a service logic interpreter which interprets 
the rules governing logic flow and accordingly invokes the 
EE functions corresponding to the API invocations and the 
other functions corresponding to the building block 
invocations that are traversed during interpretation of th< 
io subscriber service logic representation. 
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